---In DynoMotion@yahoogroups.com, <tk@...> wrote:

Hi EC,

Regarding the Status Delay: We are working on a fix for that.  Currently the Interpreter is working ahead so the Feed Rate/mode , Spindle Speed/mode, Line number, fixture, tool length, etc might have changed and isn't in sync with the machine for status display purposes.  We are now maintaining a parallel and delayed Interpreter State that should more closely match the machine.

Are you willing to test?

Regards
TK

Group: DynoMotion	Message: 9272	From: ericncn	Date: 2/27/2014
Subject: Re: Feeds Overrides Revisited

What about a totally different approach? Keep a second lookahead buffer. When the FRO is changed you compute the new trajectory data in the second buffer then you swap the two buffers. It's a bit tricky to do it in sync with the motion, but you have to change nothing in your existing math regarding accelerations speed etc. and will require none of the compromises you're describing below... Just thinking loud! EC ---In DynoMotion@yahoogroups.com, <tk@...> wrote: Hi Guys, We are always thinking about ways to do instant FRO.  We know how important it is.  But it is very difficult.  Its embarrassing that your DynoPath has it and we don't.  What model is it and how does it work?  Does it allow FRO greater than 1.0?  If so how much?  Can it also look ahead hundreds of blocks and smooth and optimize irregular 3D motion? KFLOP already has this "multiplier" type of capability for FeedHold that you seem to be describing using these variables:    extern double CS0_TimeBase;          // how much coordinated motion is advanced each tick extern double CS0_TimeBaseDelta;      // how much coordinated motion time rate is changed per tick This is like increasing or decreasing the Clock rate of the motion.  Like turning the crank faster or slower.  Under normal conditions a servo/trajectory sample cycle occurs every 90us and trajectory time is advanced by 90us.  This would be normal "real time".  By changing the amount the "Time" is advanced every 90us the motion rate can be changed. But there is a big problem with this simplistic approach - it changes all the accelerations dramatically.  It is like watching a slow motion or fast motion movie.  Things are very unrealistic.  Or imagine you have a sports car and optimize a trajectory for it to accelerate from 0 to 100mph in 10 seconds (which it can do).  Then you set the FRO to 2X.  Time will run twice as fast so the final trajectory speed will go to 200MPH but the acceleration will occur over 5 seconds.  The speed might be too high for the car and also the acceleration is 4X over the cars capability. To even allow a 20% increase in FRO the system would need to operate normally with 44% lower acceleration.  I suppose on machines that cut slowly this would be a good tradeoff. A similar thing happens with a FRO of 0.5.  In this case none of the car's capabilities will be ever exceeded.  But the car will then accelerate to only 50MPH over 20 seconds which is 4X below its optimal capability.  Unnecessarily slow through tight curves and so forth. Right now all motion with FRO is always properly constrained and fully optimized by the Trajectory Planner - but with the dreaded delay.  Note that the delay can be minimized by adjusting the buffer time to the minimum that your PC needs to avoid buffer starvation. One thing we might do as a compromise is to handle FRO less than 1 using the "rate of time" method and FRO greater than 1 in the Lookahead Trajectory Planner.  This would mean for example: #1 - FRO=1.0 would always be fully optimal using full accelerations where needed #2 - Changing FRO from 1.0 to 0.5 would be instant (but then have sub-optimal accelerations) #3 - Changing FRO from 0.5 to 1.0 would be instant (and return accelerations to optimal) #4 - Changing FRO from 1.0 to 1.5 would be delayed (but still have optimal accelerations) #5 - Changing FRO from 1.5 to 0.5 would instantly change the FRO to 0.75 then after a delay it would change to 0.5   I worry that this would have a bad "feel" when adjusting around 1.0. The cutoff wouldn't necessarily need to be at 1.0.  It could be at say 1.2 if optimal accelerations weren't needed in the normal case. What do you think? Regards TK Group: DynoMotion Message: 9273 From: Tom Kerekes Date: 2/27/2014 Subject: Re: Feeds Overrides Revisited Hi EC, Yes there will be some risk.  It will be a few days before we are ready anyways. Thanks TK Group: DynoMotion Message: 9274 From: az@aimele.com Date: 2/27/2014 Subject: Re: Feeds Overrides Revisited Tom: I think the existing time per tick and distance per tick  multiplier would work very well. I come from an NC (back in the day) and CNC service background and the time base variation approach is how feedrates were done.  All the motion was set up in X and Y hardware registers and "clocked" through with a feed rate pulse train.  The max feedrate override was 120%.   The accel decel rates were not programmable on those machines as they based their accel/decel on following error building up while the pulses accumulated error up to the desired feedrate. I can't think of any harm in doing the same thing effectively as you describe by changing the time increment per tick or the motion increment per tick.   Changing the effective ramping with this approach is actually natural and desireable because it means the tool will be at the same physical location on the part when the accel is completed at  20 % feedrate as it is when at 100% feedrate. or even 200% feedrate.  The only issue being machine dynamics and motor power.  Therefore the machines accel / decel would be specified at the maximum machine speed and the change in feedrate could only be slower than max so no issues with machine dynamics. Programmed feedrates would be achieved according to the programmed accel rates.   FRO reductions would flatten the accel decel ramps with respect to time but in my estimation this is inconsequential because most machines can accelerate 0 to 500 IPM in about  200 milliseconds which is a small physical distance.   Most parts are machined at significantly lower feeds than the machine is capable of anyway so no machine dynamics come into play in 99% of the part programs even if you were to allow 200 % FRO.   The only dynamics that could be affected are G00 moves or rapid.  These could have their own accel and speed limits as the Kflop now has anyway. ------- Original Message ------- From : Tom Kerekes[mailto:tk@...] Sent : 2/27/2014 12:20:46 PM To : DynoMotion@yahoogroups.com Cc : Subject : RE: Re: [DynoMotion] RE: Feeds Overrides Revisited   Hi Guys, We are always thinking about ways to do instant FRO.  We know how important it is.  But it is very difficult.  Its embarrassing that your DynoPath has it and we don't.  What model is it and how does it work?  Does it allow FRO greater than 1.0?  If so how much?  Can it also look ahead hundreds of blocks and smooth and optimize irregular 3D motion? KFLOP already has this "multiplier" type of capability for FeedHold that you seem to be describing using these variables:    extern double CS0_TimeBase;          // how much coordinated motion is advanced each tick extern double CS0_TimeBaseDelta;      // how much coordinated motion time rate is changed per tick This is like increasing or decreasing the Clock rate of the motion.  Like turning the crank faster or slower.  Under normal conditions a servo/trajectory sample cycle occurs every 90us and trajectory time is advanced by 90us.  This would be normal "real time".  By changing the amount the "Time" is advanced every 90us the motion rate can be changed. But there is a big problem with this simplistic approach - it changes all the accelerations dramatically.  It is like watching a slow motion or fast motion movie.  Things are very unrealistic.  Or imagine you have a sports car and optimize a trajectory for it to accelerate from 0 to 100mph in 10 seconds (which it can do).  Then you set the FRO to 2X.  Time will run twice as fast so the final trajectory speed will go to 200MPH but the acceleration will occur over 5 seconds.  The speed might be too high for the car and also the acceleration is 4X over the cars capability. To even allow a 20% increase in FRO the system would need to operate normally with 44% lower acceleration.  I suppose on machines that cut slowly this would be a good tradeoff. A similar thing happens with a FRO of 0.5.  In this case none of the car's capabilities will be ever exceeded.  But the car will then accelerate to only 50MPH over 20 seconds which is 4X below its optimal capability.  Unnecessarily slow through tight curves and so forth. Right now all motion with FRO is always properly constrained and fully optimized by the Trajectory Planner - but with the dreaded delay.  Note that the delay can be minimized by adjusting the buffer time to the minimum that your PC needs to avoid buffer starvation. One thing we might do as a compromise is to handle FRO less than 1 using the "rate of time" method and FRO greater than 1 in the Lookahead Trajectory Planner.  This would mean for example: #1 - FRO=1.0 would always be fully optimal using full accelerations where needed #2 - Changing FRO from 1.0 to 0.5 would be instant (but then have sub-optimal accelerations) #3 - Changing FRO from 0.5 to 1.0 would be instant (and return accelerations to optimal) #4 - Changing FRO from 1.0 to 1.5 would be delayed (but still have optimal accelerations) #5 - Changing FRO from 1.5 to 0.5 would instantly change the FRO to 0.75 then after a delay it would change to 0.5   I worry that this would have a bad "feel" when adjusting around 1.0. The cutoff wouldn't necessarily need to be at 1.0.  It could be at say 1.2 if optimal accelerations weren't needed in the normal case. What do you think? Regards TK Group: DynoMotion Message: 9275 From: az@aimele.com Date: 2/27/2014 Subject: Re: Feeds Overrides Revisited Tom: Responding to your suggested instant FRO options 1 through 5. I'm of the opinion that all the changes up to FRO of over 1.5 could be instant (your examples 1 through 4) The accel rates programmed for the machine would have to be set accordingly.  If that means that some machines would be operating at less than max accel/decel ramps when running at 100% FRO and programmed feedrates they could "fudge" their feedrates or set their FRO to 150% as a baseline. None of this seems like a big problem in the real world and the benefits are HUGE. FRO over 1.5 would be delayed. and FRO down from over 1.5 would follow your #5 example. The only thing I'm also considering is the rate of change of the FRO value in the case that the FRO changes faster than the axes can accel/ decel when running at a constant programmed feedrate. In that case it may be a good idea to have a max FRO rate of change parameter.   AZ ------- Original Message ------- From : Tom Kerekes[mailto:tk@...] Sent : 2/27/2014 12:20:48 PM To : DynoMotion@yahoogroups.com Cc : Subject : RE: Re: [DynoMotion] RE: Feeds Overrides Revisited   Hi Guys, We are always thinking about ways to do instant FRO.  We know how important it is.  But it is very difficult.  Its embarrassing that your DynoPath has it and we don't.  What model is it and how does it work?  Does it allow FRO greater than 1.0?  If so how much?  Can it also look ahead hundreds of blocks and smooth and optimize irregular 3D motion? KFLOP already has this "multiplier" type of capability for FeedHold that you seem to be describing using these variables:    extern double CS0_TimeBase;          // how much coordinated motion is advanced each tick extern double CS0_TimeBaseDelta;      // how much coordinated motion time rate is changed per tick This is like increasing or decreasing the Clock rate of the motion.  Like turning the crank faster or slower.  Under normal conditions a servo/trajectory sample cycle occurs every 90us and trajectory time is advanced by 90us.  This would be normal "real time".  By changing the amount the "Time" is advanced every 90us the motion rate can be changed. But there is a big problem with this simplistic approach - it changes all the accelerations dramatically.  It is like watching a slow motion or fast motion movie.  Things are very unrealistic.  Or imagine you have a sports car and optimize a trajectory for it to accelerate from 0 to 100mph in 10 seconds (which it can do).  Then you set the FRO to 2X.  Time will run twice as fast so the final trajectory speed will go to 200MPH but the acceleration will occur over 5 seconds.  The speed might be too high for the car and also the acceleration is 4X over the cars capability. To even allow a 20% increase in FRO the system would need to operate normally with 44% lower acceleration.  I suppose on machines that cut slowly this would be a good tradeoff. A similar thing happens with a FRO of 0.5.  In this case none of the car's capabilities will be ever exceeded.  But the car will then accelerate to only 50MPH over 20 seconds which is 4X below its optimal capability.  Unnecessarily slow through tight curves and so forth. Right now all motion with FRO is always properly constrained and fully optimized by the Trajectory Planner - but with the dreaded delay.  Note that the delay can be minimized by adjusting the buffer time to the minimum that your PC needs to avoid buffer starvation. One thing we might do as a compromise is to handle FRO less than 1 using the "rate of time" method and FRO greater than 1 in the Lookahead Trajectory Planner.  This would mean for example: #1 - FRO=1.0 would always be fully optimal using full accelerations where needed #2 - Changing FRO from 1.0 to 0.5 would be instant (but then have sub-optimal accelerations) #3 - Changing FRO from 0.5 to 1.0 would be instant (and return accelerations to optimal) #4 - Changing FRO from 1.0 to 1.5 would be delayed (but still have optimal accelerations) #5 - Changing FRO from 1.5 to 0.5 would instantly change the FRO to 0.75 then after a delay it would change to 0.5   I worry that this would have a bad "feel" when adjusting around 1.0. The cutoff wouldn't necessarily need to be at 1.0.  It could be at say 1.2 if optimal accelerations weren't needed in the normal case. What do you think? Regards TK Group: DynoMotion Message: 9276 From: aguskov1987 Date: 2/27/2014 Subject: Re: Feeds Overrides Revisited This was actually my initial idea - recompute trajectory and swap the buffer as soon as change in FRO is detected. However, now when I think about it, it does seem problematic. The buffer cannot be changed instantly, there will be some delay. You basically drop all control of the movement for a fraction of a second. The axes will still be moving due to inertia, most likely at different speeds screwing up the trajectory. Not good. Back to the drawing board. Andrey Group: DynoMotion Message: 9277 From: ericncn Date: 2/28/2014 Subject: Re: Feeds Overrides Revisited It depends on how the buffers are managed and what do you mean by "swap" the buffers.  As I said it's tricky, but it'ld be worth the thinking effort. I assume the buffers are something like a list of "movement instructions" that are executed one by one. Let's say we have a pointer to the next instruction to be executed that's always updated to next one as soon as current instruction's execution begins. Now let's add the second buffer and also add a second pointer (pointing in the second buffer), that's kept updated in parallel to the main one. When you want to "swap" the buffers what you actually do is to have the main pointer point to the correct position in the second buffer (i.e. you copy the value of the second pointer in the main pointer). This takes no additional time and you do it WHILE current instruction is exectuted. There should be no drop of control. You would need to update the main pointer anyway but instead of doing, say:             main_ptr = main_ptr+1; you do instead:            main_ptr = secondary_ptr; Are we talking about same thing? Maybe I've just written a bunch of errors! :-) Regards, EC ---In DynoMotion@yahoogroups.com, <aguskov1987@...> wrote: This was actually my initial idea - recompute trajectory and swap the buffer as soon as change in FRO is detected. However, now when I think about it, it does seem problematic. The buffer cannot be changed instantly, there will be some delay. You basically drop all control of the movement for a fraction of a second. The axes will still be moving due to inertia, most likely at different speeds screwing up the trajectory. Not good. Back to the drawing board. Andrey Group: DynoMotion Message: 9278 From: Tom Kerekes Date: 2/28/2014 Subject: Re: Feeds Overrides Revisited Hi AZ, Thanks for all the information.  I didn't think the "clocked" FRO would be acceptable.   But I think you are right for machines that cut relatively slow acceleration is not an issue so it would work well.  I think for higher performance machines and routers it would be more of an issue.  But providing an optional "Hardware FRO" threshold would allow the User to have it either way they want.  We will look into this. BTW I liked your description of: >>>"The accel decel rates were not programmable on those machines as they based their accel/decel on following error building up while the pulses accumulated error up to the desired feedrate" I think what you are saying is that the motion was generated as simple Constant Velocity (infinite acceleration) and the servo tuning determined how the axis accelerated to catch up with the moving trajectory.  Very interesting.  Regards TK Group: DynoMotion Message: 9279 From: Tom Kerekes Date: 2/28/2014 Subject: Re: Feeds Overrides Revisited Hi EC, "Somewhat Tricky" is an understatement :} Switching buffer pointers is not really the issue.  The problem is that the two trajectories are different.  Simply switching to a different trajectory would result in a discontinuity in position and velocity. Besides that there are the time delays involved.  Windows and the Trajectory Planner are not real-time.   Sometimes Windows "freezes" applications doing things for up to a second or more.  That is why the Interpreter needs to sometimes work hundreds of blocks ahead which generate thousands of motion segments ahead which in turn create tens-of thousands of trajectory points ahead.  So the situation could be more like: #1 - Stop adding to the several seconds of motion at the current FRO that we currently already have in KFLOP #2 - Backup the interpreter upto several hundred blocks to where the machine actually is #3 - change FRO #3 - re-interpret those several hundred GCode Blocks #4 - Trajectory Plan the motion generating possibly several thousand motion segments #5 - Download those to KFLOP #6 - Instruct KFLOP to somehow on-the-fly transition from the original trajectory to the new trajectory ASAP Regards TK Group: DynoMotion Message: 9280 From: Tom Kerekes Date: 2/28/2014 Subject: Re: Feeds Overrides Revisited Hi EC, "Somewhat Tricky" is an understatement :} Switching buffer pointers is not really the issue.  The problem is that the two trajectories are different.  Simply switching to a different trajectory would result in a discontinuity in position and velocity. Besides that there are the time delays involved.  Windows and the Trajectory Planner are not real-time.   Sometimes Windows "freezes" applications doing things for up to a second or more.  That is why the Interpreter needs to sometimes work hundreds of blocks ahead which generate thousands of motion segments ahead which in turn create tens-of thousands of trajectory points ahead.  So the situation could be more like: #1 - Stop adding to the several seconds of motion at the current FRO that we currently already have in KFLOP #2 - Backup the interpreter upto several hundred blocks to where the machine actually is #3 - change FRO #3 - re-interpret those several hundred GCode Blocks #4 - Trajectory Plan the motion generating possibly several thousand motion segments #5 - Download those to KFLOP #6 - Instruct KFLOP to somehow on-the-fly transition from the original trajectory to the new trajectory ASAP Regards TK Group: DynoMotion Message: 9281 From: az@aimele.com Date: 2/28/2014 Subject: Re: Feeds Overrides Revisited You're welcome.  The old NC designs were pretty slick in their simplicity.   Sometimes when I'm feeling geeky,  I  think about how those original NC engineers figured out how to implement X-Y circular interpolation using clocked hardware registers with simple continuous addition with carry and borrow bits.  The Boolean algebra would give me a headache!  It was rumored that the guy(s) who designed the Transistor based NAND gate (no IC chips) NC control were locked in a room each day with walls made of chalkboards.  Then at the end of each day they would let them go home and the "sane" engineers would photograph all the diagrams on the walls and  replace all the boards with clean ones for the next day.  Eventually they came together and built an NC. control.  It may have been the GE 100.  You've got to give them a lot of credit! AZ ------- Original Message ------- From : Tom Kerekes[mailto:tk@...] Sent : 2/28/2014 2:15:05 PM To : DynoMotion@yahoogroups.com Cc : Subject : RE: Re: Re: [DynoMotion] RE: Feeds Overrides Revisited   Hi AZ, Thanks for all the information.  I didn't think the "clocked" FRO would be acceptable.   But I think you are right for machines that cut relatively slow acceleration is not an issue so it would work well.  I think for higher performance machines and routers it would be more of an issue.  But providing an optional "Hardware FRO" threshold would allow the User to have it either way they want.  We will look into this. BTW I liked your description of: >>>"The accel decel rates were not programmable on those machines as they based their accel/decel on following error building up while the pulses accumulated error up to the desired feedrate" I think what you are saying is that the motion was generated as simple Constant Velocity (infinite acceleration) and the servo tuning determined how the axis accelerated to catch up with the moving trajectory.  Very interesting.  Regards TK Group: DynoMotion Message: 9282 From: Tom Kerekes Date: 2/28/2014 Subject: Re: Feeds Overrides Revisited Yes my highest admiration to them.  Imagine walking into that room with a KFLOP :} TK Group: DynoMotion Message: 9283 From: Wcarrothers Yahoo Date: 2/28/2014 Subject: Re: Feeds Overrides Revisited Ha.  Every time I fire up my boss10 equipped Bridgeport Cnc from 1985. The operator of that back then was infront of something special.  He'll it has a serial port for gosh sakes.   I'm waiting for the day if ever something crokes on it and I have to kflop it B On Feb 28, 2014, at 8:26 PM, Tom Kerekes <tk@...> wrote:   Yes my highest admiration to them.  Imagine walking into that room with a KFLOP :} TK Group: DynoMotion Message: 9289 From: aguskov1987 Date: 3/3/2014 Subject: Re: Feeds Overrides Revisited     Wow. This is really a good discussion. Thank you everybody for some great input on this topic. Regarding the Dynapath controller we have, it is an PC based control brand new in 1995, runs on DOS.  We never tried complex 3d shapes but I do not think it would handle very well. The override goes from 0% to 175%. Feels pretty real time to me; g-d knows how they implement buffering and what not but the motion is controlled from a ISA board connected to a regular PC motherboard.     So I'm still wondering about the kflop buffering scheme. How does the KMotionCNC program manage the buffering? The way I understand it, the program opens the buffer, throws some move commands, triggers the execution and then waits for the signal from the board that the motion is complete. Ones it is complete, the pc clears the buffer, uploads the next set of commands and triggers the execution again. Or... once the buffer open, cleared, uploaded and started, the PC can still send the move commands and they would just pile in the buffer one after another? Group: DynoMotion Message: 9291 From: aguskov1987 Date: 3/3/2014 Subject: Re: Feeds Overrides Revisited OK, The buffer does not get blocked once the ExecBuf is triggered. Commands properly get stacked in the buffer and wait for execution. Didn't take long to figure that out :-P Group: DynoMotion Message: 9292 From: Tom Kerekes Date: 3/3/2014 Subject: Re: Feeds Overrides Revisited The Coordinated motion buffer works as a continuous stream.  The buffer is opened and motion segments are downloaded.  After some amount (Lookahead time) of motion is downloaded, KFLOP is triggered to begin executing the motion.  KFLOP needs to have enough motion so that if the PC/Windows/USB happens to stall for a while, KFLOP will have enough motion to endure the stall without any disruption.  GCode Execution and Trajectory Planning for additional motion is then paused so as to stay only the minimum amount necessary ahead.  The PC Polls KFLOP on how much time in the buffer has been executed.  When the remaining time in the buffer falls below the Lookahead time, then the GCode Interpreter and Trajectory Planner continue computing additional future motion (using the current FRO) and downloading to KFLOP until again the unexecuted amount in the buffer equals or exceeds the Lookahead time.  The buffer itself is a circular buffer with a max size of ~40,000 motion segments.  In a complex irregular 3D motion path each motion segment may only execute for several milliseconds. It wouldn't really work to download motion in blocks.  That could cause unnecessary stops and pauses. Well a PC+DOS+ISA bus system is actually much more real-time than MS Windows + USB (or Ethernet).  But even with a real-time system is still very difficult to do complex trajectory planning on-the-fly in real time. Thanks for the info.  I was curious what architecture the Dynapath Controller used. Regards TK  Group: DynoMotion Message: 9293 From: deanw1a Date: 3/3/2014 Subject: Re: Feeds Overrides Revisited It sounds like a buffer index array and state record array to save safe FRO change positions and planner states would be helpful. If there are such positions and if they are fairly close together in time. When the FRO is changed, the buffer would continue to be used while the trajectory planner finds the next safe position, rewinds itself using the saved state and creates new FRO motion commands in a temp buffer. Then, the newest next safe insert position would be found in the current buffer and the new FRO data could be used from there. The newest safe position could be the same or later than the one the planner rewound to. That way, the FRO change would occur as soon as it is practical without rate scaling. Perhaps it already works something like that? I have not studied trajectory planning or the code. This suggestion may be nonsense.